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What Are Permissions? 

Applies To: Windows 7, Windows Server 2008 R2 

Permissions and security descriptors 

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information 
controls the type of access allowed to users and groups. The security descriptor is automatically created along with the container or object that is 
created. A typical example of an object with a security descriptor is a file. 

Permissions are defined within an object's security descriptor. Permissions are associated with, or assigned to, specific users and groups. For example, for 
the file Temp.dat, the built-in Administrators group might be assigned Read, Write, and Delete permissions, while the Backup Operators group might be 
assigned Read and Write permissions only. 

Each assignment of permissions to a user or group is represented in the system as an access control entry (ACE). The entire set of permission entries in 
a security descriptor is known as a permission set or access control list (ACL). Thus, for a file named Temp.dat, the permission set includes two 
permission entries, one for the built-in Administrators group and one for the Backup Operators group. 

Explicit vs. inherited permissions 

There are two types of permissions: explicit permissions and inherited permissions. 

Explicit permissions are those that are set by default on non-child objects when the object is created, or by user action on non-child, parent, or 
child objects. 

Inherited permissions are those that are propagated to an object from a parent object. Inherited permissions ease the task of managing 
permissions and ensure consistency of permissions among all objects within a given container. 

By default, objects within a container inherit the permissions from that container when the objects are created. For example, when you create a folder 
called MyFolder, all subfolders and files created within MyFolder automatically inherit the permissions from that folder. Therefore, MyFolder has explicit 
permissions, while all subfolders and files within it have inherited permissions. 



jfNote 

Inherited Deny permissions do not prevent access to an object if the object has 
precedence over inherited permissions, even inherited Deny permissions. 


an 






Explicit permissions 


take 


explicit Allow permission 


entry. 



Additional references 

* File and Folder Permissions 1 

* Set, View, Change, or Remove Permissions on an Object 2 



Links Table 

1 http://technet. microsoft, com/ en- us/ library/ cc732880. aspx 
2 http:// 'technet.microsoft.com/en-us/library/cc731667.aspx 



© 2012 Microsoft. All rights reserved. 



File and Folder Permissions 



Microsoft I Tech Net 



Applies To: Windows 7, Windows Server 2008 R2 

The following table lists the access limitations for each set of special NTFS permissions. 



Special permissions 


Full Control 


Modify 


Read & Execute 


List Folder Contents (folders only) 


Read 


Write 




Traverse Folder/ Execute File 


X 


X 


X 


X 








List Folder/ Read Data 


X 


X 


X 


X 


X 






Read Attributes 


X 


X 


X 


X 


X 






Read Extended Attributes 


X 


X 


X 


X 


X 






Create Files/Write Data 


X 


X 








X 




Create Folders/ Append Data 


X 


X 








X 




Write Attributes 


X 


X 








X 




Write Extended Attributes 


X 


X 








X 




Delete Subfolders and Files 


X 














Delete 


X 


X 












Read Permissions 


X 


X 


X 


X 


X 


X 




Change Permissions 


X 














Take Ownership 


X 














Synchronize 


X 


X 


X 


X 


X 


X 




^Important 

Groups or users granted Full Control permission on a folder can delete any files in that folder regardless of the permissions protecting the file. 



Additional considerations 

Although List Folder Contents and Read & Execute appear to have the same special permissions, these permissions are inherited differently. List 
Folder Contents is inherited by folders but not files, and it should only appear when you view folder permissions. Read & Execute is inherited by 
both files and folders and is always present when you view file or folder permissions. 

In this version of Windows, the Everyone group does not include the Anonymous Logon group by default, so permissions applied to the Everyone 
group do not affect the Anonymous Logon group. 

Additional references 

* Managing Permissions 1 



Links Table 

1 http://technet.microsoft.com/en-us/library/cc770962.aspx 
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Applies To: Windows 7, Windows Server 2008 R2 

Access to a folder on a file server can be determined through two sets of permission entries: the share permissions set on a folder and the NTFS 
permissions set on the folder (which can also be set on files). Share permissions are often used for managing computers with FAT32 file systems, or 
other computers that do not use the NTFS file system. 

Share permissions and NTFS permissions are independent in the sense that neither changes the other. The final access permissions on a shared folder 
are determined by taking into consideration both the share permission and the NTFS permission entries. The more restrictive permissions are then applied. 

The following table suggests equivalent permissions that an administrator can grant to the Users group for certain shared folder types. Another approach 
is to set share permissions to Full Control for the Everyone group and to rely entirely on NTFS permissions to restrict access. 



Folder type 



Share 
permissions 



NTFS permissions 



Public folder. A folder 
that can be accessed by 
everyone. 



Grant 

Change 

permission to Grant Modify permission to the Users group. 

the Users 

group. 



Drop folder. A folder 
where users can drop 
confidential reports or 
homework assignments 
that only the group 
manager or instructor can 
read. 



Grant 
Change 
permission 
the Users 
group. 

Grant Full 
Control 
permission 
the group 
manager. 



Grant Write permission for the Users group that is applied to This Folder only. (This is an option available on 
the Advanced page.) 

to 

If each user needs to have certain permissions to the files that he or she dropped, you can create a permission 
entry for the Creator Owner well-known security identifier (SI D) and apply it to Subfolder and files only. For 
example, you can grant the Read and Write permission to the Creator Owner SID on the drop folder and apply it 
to all subfolders and files. This grants the user who dropped or created the file (the Creator Owner) the ability 
to read and write to the file. The Creator Owner can then access the file through the Run command by using 

to \ \ServerName\ DropFolder\ FileName. 

Grant Full Control permission to the group manager. 



Application folder. A Grant Read 

folder containing permission to ~ . n . n . _ ._ . , . . . ._ ., ~ . . , ,, .. 

.. .. . . r. . Tu .. Grant Read, Read & Execute, and List Folder Contents permissions to the Users group. 

applications that can be the Users 

run over the network. group. 



Home folder. An 

individual folder for each 
user. Only the user has 
access to the folder. 



Grant Full 

Control 

permission to 

each user on Grant Full Control permission to each user on his or her respective folder. 

his or her 

respective 

folder. 



Additional considerations 

Granting a user Full Control NTFS permission on a folder enables that user to take ownership of the folder unless the user is restricted in some 
other way. Be cautious in granting Full Control. 

If you want to manage folder access by using NTFS permissions exclusively, set share permissions to Full Control for the Everyone group. 

* NTFS permissions affect access both locally and remotely. NTFS permissions apply regardless of protocol. Share permissions, by contrast, apply 
only to network shares. Share permissions do not restrict access to any local user, or to any terminal server user, of the computer on which you 
have set share permissions. Thus, share permissions do not provide privacy between users on a computer used by several users, nor on a terminal 
server accessed by several users. 

By default, the Everyone group does not include the Anonymous group, so permissions applied to the Everyone group do not affect the Anonymous 
group. 

Additional references 

* Managing Permissions 1 



Links Table 

1 http://technet. microsoft.com/en-us/library/cc770962.aspx 
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Inherited Permissions 

Applies To: Windows 7, Windows Server 2008 R2 

Inherited permissions are those that are propagated to an object from a parent object. Inherited permissions ease the task of managing permissions and 
ensure consistency of permissions among all objects within a given container. 

Inheritance for all objects 

If the Allow and Deny permission check boxes in the various parts of the access control user interface are shaded when you view the permissions of an 
object, the object has inherited permissions from a parent object. You can set these inherited permissions by using the Permissions tab of the 
Advanced Security Settings properties page. 

There are three recommended ways to make changes to inherited permissions: 

Make the changes to the parent object where the permissions are explicitly defined, and then the child object will inherit these permissions. For 
more information, see Set, View, Change, or Remove Permissions on an Object 1 . 

Select the Allow permission to override the inherited Deny permission. 

Clear the I nclude inheritable permissions from this object's parent check box. Then you can make changes to the permissions or remove 
users or groups from the Permissions list. However, the object will no longer inherit permissions from the parent object. 



^Note 

Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry. 



jfNote 

Explicit permissions take precedence over inherited permissions, even inherited Deny permissions. 



If the Special Permissions entry in Permissions for <User or Group> is shaded, it does not imply that this permission has been inherited. This means 
that a special permission has been selected. 

On the Permissions tab of the Advanced Security Settings for <Folder> page, in Permission entries, the Apply To column lists what folders or 
subfolders a permission is applied to. The Inherited From column lists where the permissions have been inherited from. 

You can use the Apply To field of the Permission Entry for<Folder> page to select the folders or subfolders you want permissions to be applied to. 

For more information about how to complete these tasks, see Set, View, Change, or Remove Permissions on an Object 1 and Determine Where to Apply 
Permissions 2 . 

Inheritance for Active Directory objects 

If you use an Apply To option to control inheritance for Active Directory objects, be aware that not only do the objects specified in the Apply To box 
inherit that access control entry (ACE), but also all child objects also receive a copy of that ACE. The child objects that are not specified in the Apply 
To box receive copies of the ACE but do not enforce it. If there are enough objects getting copies of this ACE, then that increased amount of data can 
cause serious performance problems to your network. 

If you assign permissions to a parent object and want child objects to inherit these permission entries, you can keep performance optimal by making sure 
all the child objects have identical access control lists (ACLs). In Windows, single-instancing allows Active Directory Domain Services (AD DS) to store 
only one copy of all identical ACLs. By creating ACLs that many objects can use, you can preserve the performance of your network. 

Additional references 

For more information about permissions, see What Are Permissions? 3 . 

* For more information about permissions for Active Directory objects, see Access control in Active Directory 4 (http://go.microsoft.com/fwlink/? 
Linkld=63972). 



Links Table 

1 http://technet. microsoft.com/en-us/library/cc731667.aspx 
2 http://technet. microsoft.com/en-us/library/cc771309.aspx 
3 http://technet. microsoft.com/en-us/library/cc771375.aspx 
4 http://go. microsoft. com/fwlink/?Linkl 6=63972 
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How Effective Permissions Are Determined 

Applies To: Windows 7, Windows Server 2008 R2 

Each object has a set of effective permissions associated with it. The Effective Permissions tab of the Advanced Security Settings property page 
lists the permissions that would be granted to the selected group or user based solely on the permissions granted directly through group membership. If 
you want to find out what permissions a user or group has on an object, you can use the Effective Permissions tool. 

Factors that are used to determine effective permissions 

The following are used to determine effective permissions: 
Global group membership 
Local group membership 
Local permissions 
Local privileges 
Universal group membership 

Factors that are not used to determine effective permissions 

The following well-known security identifiers (SIDs) are not used to determine effective permissions: 
Anonymous Logon 
Batch, Creator Group 
Dialup 

Enterprise Domain Controllers 
Interactive 
Network 
Proxy 
Restricted 
Remote 
Service 
System 
* Terminal Server User 
Other Organization 
This Organization 

Also, share permissions are not part of the effective permissions calculation. Access to shares can be denied through share permissions even when 
access is allowed through NTFS permissions. 

Factors that are not used for objects that are accessed remotely 

The following are not used to determine effective permissions for objects that are accessed remotely: 
Local group membership 
Local privileges 
Share permissions 

Effective permissions are based on a local evaluation of the user's group membership, user privileges, and permissions. If the resource being queried is on 
a remote computer, the effective permissions displayed will not include permissions granted or denied to the user through the use of a local group on the 
remote computer. 

Retrieving effective permissions 

Accurate retrieval of the above information requires permission to read the membership information. If the specified user or group is a domain object, you 
must have permission to read the object's group information about the domain. 



41 important 

When you use the Effective Permissions tab to determine the permissions that a user has for certain resources in a domain, the results that are 
displayed in the user interface may be inconsistent with the actual permissions of the user for that resource. This problem occurs when one of the 
following conditions is true: 

You run the administrative tools remotely from the resource server. 



* The user account that you use to run the administrative tools is not in the same domain as the resource. 

To avoid this problem, always check effective permissions locally on a computer that hosts the resource, and make sure that the administrative user 
account used to run the tool is in the same domain as the resource. 



Here are some relevant default domain permissions: 

Domain administrators have permission to read membership information about all objects. 

Local administrators on a workstation or stand-alone server cannot read membership information for a domain user. 

Effective Permissions tool 

If you want to find out what permissions a user or group has on an object, you can use the Effective Permissions tool. It calculates the permissions that 
are granted to the specified user or group. The calculation includes the permissions in effect from group membership and any permissions inherited from 
the parent object. It looks up all domain and local groups in which the user or group is a member. 

The Everyone group will always be included, as long as the selected user or group is not a member of the Anonymous Logon group. 



^Important 

The Effective Permissions tool only produces an approximation of the permissions that a user has. The actual permissions the user has may be 
different because permissions can be granted or denied based on how a user logs on. This logon-specific information cannot be determined by the 
Effective Permissions tool if the user is not logged on; therefore, the effective permissions it displays reflect only those permissions specified by the 
user or group and not the permissions specified by the logon. 

For example, if a user is connected to this computer through a shared folder, then the logon for that user is marked as a network logon. Permissions 
can be granted or denied to the Network well-known SID, which the connected user receives, so a user has different permissions when logged on 
locally than when logged on over a network. 

For information about granting access for effective permissions, see article 331951 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/? 
Linkld=63270 1 ). 



For information about using the Effective Permissions tool, see View Effective Permissions on Files and Folders 2 . 
Additional references 

* Managing Permissions 3 





1 http://go. microsoft. com/fwlink/?Linkl 6=63270 


2 http://technet.microsoft.com/en-us/library/cc771586.aspx 


3 http://technet.microsoft.com/en-us/library/cc770962.aspx 
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Determine Where to Apply Permissions 

Applies To: Windows 7, Windows Server 2008 R2 

When you set advanced permissions on files and folders, you can use the Permission Entry for <Object Name> dialog box to set which descendant 
objects will inherit permissions. 

To find this dialog box, click Advanced on the access control user interface. On the Permissions tab, click Edit twice. 

I n the Permission Entry for <Object Name> dialog box, the Apply onto box on the Object tab lists the locations where you can apply permissions. 
How these permissions are applied depends on whether you select the Apply these permissions to objects and/ or containers within this container 
only check box. 



4M important 

For Active Directory objects, not only do the specified objects in the Apply onto box inherit the access control entries but all child objects also 
receive a copy of that ACE. The child objects not specified in the Apply onto box do not use the ACE whose copy they receive, but if enough 
objects get copies of this ACE, that increased amount of data can cause serious performance problems to your network. 



By default, this check box is cleared. See the following tables for details about how the inherited permissions are applied: 

* When the Apply these permissions to objects and/or containers within this container only check box is cleared 

* When the Apply these permissions to objects and/or containers within this container only check box is selected 

When the Apply these permissions to objects and/or containers within this container only check box is cleared 



Applies Applies permissions to 
Apply onto permissions to subfolders in current 
current folder folder 


Applies permissions to Applies permissions to all Applies permissions to files 
files in current folder subsequent subfolders in all subsequent subfolders 


This folder only 


X 










This folder, 
subfolders, and 
files 

This folder and 
subfolders 


X 


X 


X 


X 


X 


X 


X 




X 




This folder and 
files 


X 




X 




X 


Subfolders and 
files only 




X 


X 


X 


X 


Subfolders only 




X 




X 




Files only 






X 




X 



When the Apply these permissions to objects and/or containers within this container only check box is selected 



Applies Applies permissions to 
Apply onto permissions to subfolders in current 
current folder folder 


Applies permissions to Applies permissions to all Applies permissions to files 
files in current folder subsequent subfolders in all subsequent subfolders 


This folder only 


X 










This folder, 
subfolders, and 
files 


X 


X 


X 






This folder and 
subfolders 


X 


X 








This folder and 
files 


X 




X 






Subfolders and 
files only 




X 


X 






Subfolders only 




X 








Files only 






X 







Additional references 

For information about where to assign permissions to Active Directory objects, see Best practices for assigning permissions on Active Directory objects 1 
(http://go.microsoft.com/fwlink/7Linkl d=63971). 

For more information about setting permissions, see the following: 

* File and Folder Permissions 2 

• Set, View, Change, or Remove Permissions on an Object 3 



Links Table 


1 http://go. microsoft, com/ fwlink/? Link! 6-63971 


2 http://technet. microsoft, com/ en- us/ library/ cc732880. aspx 


3 http://technet.microsoft.com/en-us/library/cc731667.aspx 
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